[UPDATE] Amazon IVSのLow-Latency Streamingでポリシーによる再生制限ができるようになりました!
はじめに
清水です。本エントリでお届けするアップデート情報はこちら!AWSのマネージド型ライブストリーミングソリューションであるAmazon Interactive Video Service (Amazon IVS)のLow-Latency Streamingでポリシーによる再生制限ができるPlayback restriction policiesが利用可能になりました。2024/02/01 16:00 JSTの段階でAWS What's Newなどへのポストはありませんが、Amazon IVS Low-Latency Streaming User GuideのDocument Historyから現地時間2024/01/31付でアップデートがあったことが確認できます。
Document History (Low-Latency Streaming) - Amazon Interactive Video Service
これまでもAmazon IVSのLow-Latency StreamingではJSON Web Token (JWT)を使った再生制限、プライベートチャンネルが利用可能でした。2020年夏のアップデートでしたね。
このプライベートチャンネルでは、再生時(Playback URLアクセス時)に正しいtokenを含んでいるかをもとに制限を行っていました。新たに利用可能になったPlayback restriction policiesではtokenは必要なく、代わりに設定したpolicy内容でIVS Channel側が制限を行います。制限の判断基準は、アクセス元の国(Countries)ならびにアクセス元(プレイヤーを埋め込んだ)のサイト(Origin)です。tokenによる制限よりも厳密ではありませんが、GeoBlockingや意図しないWebサイトへの埋め込み防止などを簡単に実現できます。
本エントリでは、このIVS Low-Latency StreamingのPlayback restriction policiesによる再生制限を実際に試してみたのでまとめてみたいと思います。
Playback restriction policyの作成
Playback restriction policiesによる再生制限の確認、まずはこのPlayback restriction policyの作成から進めます。Amazon IVSマネジメントコンソールにアクセスしましょう。IVSリリース時にくらべて機能がたくさん増えたなぁなどとニヤニヤしつつ、Low-latency streamingの項目、Playback securityにPlayback restriction policiesが増えていますね!
Playback restriction policiesのページに進み、[Create policy]ボタンを押下します。
Create policy画面に進みます。Playback restriction policy nameを適切に入力しましょう。Strict origin enforcementはデフォルトの無効のまま進めました。Allowed countriesではJP Japan
を選択、Allowed originsについてもいったん空欄のまま、[Create policy]でPolicyを作成しましょう。
Playback restriction policyが作成できました。
Playback restriction policyをChannelに設定
続いて、IVS Low-latency streamingのChannelを作成します。Setupの項目、Channel nameを適切に入力し、Channel configurationはDefault configuration
で進めます。
Restrict playbackの項目でEnable playback restrictionをonにします。Playback restriction policyで先ほど作成したpolicyを選択しましょう。
Channelが作成できました。Channel詳細画面でもPlayback restrictionの項目が追加されていますね。
Playback restriction policyでの再生制限の確認
Playback restriction policyを設定したChannelが作成できました。それでゃ実際にPlayback restriction policyでの再生制限について確認していきましょう。該当Channelに対してIVSマネジメントコンソール経由で検証用のライブストリーミングを開始します。
Allowed countriesによる再生制限の確認
Playback画面で問題なく再生できている(再生が制限されていない)ことをまず確認しておきましょう。なお、マネジメントコンソールには日本国内からアクセスしている状態です。
続いてPlayback URLに対してcurlコマンドを叩きレスポンス内容を確認してみます。こちらも日本国内からPlayback URLにアクセスしています。以下のようにステータスコード200
が返り、マニフェストファイルの取得に成功している(=再生ができる)状態ですね。
% curl -I https://62xxxxxxxx2b.ap-northeast-1.playback.live-video.net/api/video/v1/ap-northeast-1.123456789012.channel.uZxxxxxxxx2u.m3u8 HTTP/2 200 content-type: application/vnd.apple.mpegurl content-length: 6151 vary: Accept-Encoding date: Thu, 01 Feb 2024 09:53:43 GMT access-control-allow-origin: * x-amzn-trace-id: Root=1-65xxxx27-37xxxxxxxxxxxxxxxxxxxx33 x-amzn-trace-id: Root=1-65xxxx27-37xxxxxxxxxxxxxxxxxxxx33 x-cache: Miss from cloudfront via: 1.1 a2xxxxxxxxxxxxxxxxxxxxxxxxxxxx72.cloudfront.net (CloudFront) x-amz-cf-pop: NRT57-C1 x-amz-cf-id: 1lsrxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxOg==
先ほど作成してこのChannelにアタッチしたPlayback restriction policyでは、日本国内からのアクセスのみ許可する設定でした。日本国外からPlayback URLにアクセスするケースも確認してみましょう、オレゴンリージョン(us-west-2)でCloudShellを実行してアメリカ国内からのアクセスを再現してみました。以下のように、スタータスコード403
が返りクエストに失敗していることが確認できます。アクセス元の国による再生制限、GeoBlockingが実現できていますね!
[cloudshell-user@ip-10-136-120-99 ~]$ curl -i https://62xxxxxxxx2b.ap-northeast-1.playback.live-video.net/api/video/v1/ap-northeast-1.123456789012.channel.uZxxxxxxxx2u.m3u8 HTTP/2 403 content-type: application/json content-length: 167 date: Thu, 01 Feb 2024 09:58:28 GMT access-control-allow-origin: * x-amzn-trace-id: Root=1-65xxxx43-7axxxxxxxxxxxxxxxxxxxxec x-amzn-trace-id: Root=1-65xxxx43-7axxxxxxxxxxxxxxxxxxxxec x-cache: Error from cloudfront via: 1.1 a8xxxxxxxxxxxxxxxxxxxxxxxxxxxxdc.cloudfront.net (CloudFront) x-amz-cf-pop: HIO50-C2 x-amz-cf-id: p6_UxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxRQ== [{"url":"/api/video/v1/ap-northeast-1.123456789012.channel.uZxxxxxxxx2u.m3u8","error":"Content Restricted In Region","error_code":"content_geoblocked","type":"error"}]
なお、上記で確認したケースとは逆にPlayback restriction policyでUS United States of America
のみを許可とすれば、日本国内からのアクセスは403
で再生不可、オレゴンリージョンのCloudShellからPlayback URLに対してcurlコマンドを叩くと200
が返る、という結果となります。
Allowed originsによる再生制限の確認
続いてアクセス元のサイト(Originヘッダ)による再生制限についても確認してみましょう。現状、このChannelにアタッチしたPlayback restriction policyではAllowed originsは指定していない状況です。上記のようにマネジメントコンソールからの再生ができるほか、Playback URLのレスポンスヘッダではaccess-control-allow-origin: *
が確認できます。
% curl -I https://62xxxxxxxx2b.ap-northeast-1.playback.live-video.net/api/video/v1/ap-northeast-1.123456789012.channel.uZxxxxxxxx2u.m3u8 HTTP/2 200 content-type: application/vnd.apple.mpegurl content-length: 6140 vary: Accept-Encoding date: Thu, 01 Feb 2024 10:16:05 GMT access-control-allow-origin: * x-amzn-trace-id: Root=1-65xxxx65-10xxxxxxxxxxxxxxxxxxxxfe x-amzn-trace-id: Root=1-65xxxx65-10xxxxxxxxxxxxxxxxxxxxfe x-cache: Miss from cloudfront via: 1.1 38xxxxxxxxxxxxxxxxxxxxxxxxxxxx20.cloudfront.net (CloudFront) x-amz-cf-pop: NRT57-C1 x-amz-cf-id: Jl2nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx9w==
このChannelにアタッチしている、先ほど作成したPlayback restriction policiesの詳細ページ、[Edit]ボタンから進みます。
Allowed originsの項目の[Add origins]ボタンを押下して再生を許可するOriginを追加します。
許可するOrigin(再生を許可するサイトドメイン)として https://ivs.example.net を追加しました。
再生を許可するOriginを追加したあと、マネジメントコンソールのPlayback画面を確認してみます。マネジメントコンソールは再生を許可するサイトに含まれていない状態ですので、再生はできずにPlayback error
が表示されますね。
Allowed originsで追加したドメインのサイト(ここでは https://ivs.example.net )に埋め込んだIVS Playerからであれば、再生が可能です。
Playback URLに対するレスポンスヘッダについても確認してみましょう。リクエスト時にOriginヘッダがない場合、もしくはAllowed originsで追加したものと同一のOriginヘッダではない場合、リクエストには成功して200
は返りますが、レスポンスヘッダにaccess-control-allow-origin
は含まれません。
% curl -I https://62xxxxxxxx2b.ap-northeast-1.playback.live-video.net/api/video/v1/ap-northeast-1.123456789012.channel.uZxxxxxxxx2u.m3u8 HTTP/2 200 content-type: application/vnd.apple.mpegurl content-length: 6140 vary: Accept-Encoding date: Thu, 01 Feb 2024 10:59:02 GMT x-amzn-trace-id: Root=1-65xxxx76-74xxxxxxxxxxxxxxxxxxxxd2 x-amzn-trace-id: Root=1-65xxxx76-74xxxxxxxxxxxxxxxxxxxxd2 x-cache: Miss from cloudfront via: 1.1 05xxxxxxxxxxxxxxxxxxxxxxxxxxxxe4.cloudfront.net (CloudFront) x-amz-cf-pop: NRT57-C1 x-amz-cf-id: yE709xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxw==
% curl -H "Origin: https://not-allowed-site.example.net" -I https://62xxxxxxxx2b.ap-northeast-1.playback.live-video.net/api/video/v1/ap-northeast-1.123456789012.channel.uZxxxxxxxx2u.m3u8 HTTP/2 200 content-type: application/vnd.apple.mpegurl content-length: 6137 vary: Accept-Encoding date: Thu, 01 Feb 2024 10:59:42 GMT x-amzn-trace-id: Root=1-65xxxx9e-63xxxxxxxxxxxxxxxxxxxxd9 x-amzn-trace-id: Root=1-65xxxx9e-63xxxxxxxxxxxxxxxxxxxxd9 x-cache: Miss from cloudfront via: 1.1 d5xxxxxxxxxxxxxxxxxxxxxxxxxxxx8a.cloudfront.net (CloudFront) x-amz-cf-pop: NRT57-C1 x-amz-cf-id: tG9FxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxSQ==
対して、Allowed originsで指定したものと同じOriginヘッダがある場合は、レスポンスヘッダに access-control-allow-origin: https://ivs.example.net と許可したサイトドメインが含まれるかたちです。
% curl -H "Origin: https://ivs.example.net" -I https://62xxxxxxxx2b.ap-northeast-1.playback.live-video.net/api/video/v1/ap-northeast-1.123456789012.channel.uZxxxxxxxx2u.m3u8 HTTP/2 200 content-type: application/vnd.apple.mpegurl content-length: 6137 vary: Accept-Encoding date: Thu, 01 Feb 2024 10:26:35 GMT access-control-allow-origin: https://ivs.example.net x-amzn-trace-id: Root=1-65xxxxda-57xxxxxxxxxxxxxxxxxxxx96 x-amzn-trace-id: Root=1-65xxxxda-57xxxxxxxxxxxxxxxxxxxx96 x-cache: Miss from cloudfront via: 1.1 f3c5f4930da878ee6625af13df3ad240.cloudfront.net (CloudFront) x-amz-cf-pop: NRT57-C1 x-amz-cf-id: TpJIM15WdCmL2YrVNCHIVXjNo2rjswPpbz5GClFgwX7IDeWUhE3h7g==
このaccess-control-allow-origin
ヘッダがないとブラウザ上でCORSエラーが発生、プレイヤーで動画再生ができません。アクセス元の(プレイヤーを埋め込んだ)サイトによる再生制限が行われていることが確認できますね。
なお本エントリでは動作確認を省略しますが、User Guideによるとstrict origin enforcementを有効にすることで、このトップレベルマニフェストファイル(multivariant playlist)のaccess-control-allow-origin
レスポンスヘッダだけではなく、ほかマニフェストファイル(variant playliset)やセグメントファイルに対してもOriginヘッダが合致するかの確認を行うようです。より厳密にアクセス元の制限を行いたい場合はstrict origin enforcementの有効化を検討してみましょう。
まとめ
Amazon Interactive Video Service (Amazon IVS)のLow-Latency Streamingで新たに利用可能になったPlayback restriction policiesを使って、アクセス元の国による再生制限(GeoBlocking)とアクセス元のサイト(プレイヤーを埋め込んだサイト、Origin)による再生制限を試してみました。
これまでのIVS Low-Latency StreamingのPrivate Channel、tokenによる制限よりも厳密ではありませんが、ライブ動画出力にかかるコスト(料金)が視聴者のアクセス元(厳密には接続しているIVSサーバの場所)によって決まることも考えると、サクッとアクセス元の国による再生制限をかけられるのは嬉しいアップデートかと思います。上手に使い分けていきましょう。